[CODE BLUE 2019]APIに起因するSSRF：Apple PayがWeb全体にいかに脆弱性をばらまいたか[レポート] #codeblue_jp

こんにちは、臼田です。

『世界トップクラスのセキュリティ専門家による日本発の情報セキュリティ国際会議』でありますCODE BLUE 2019に参加していますのでレポートします。

このブログは下記セッションについてのレポートです。

APIに起因するSSRF：Apple PayがWeb全体にいかに脆弱性をばらまいたか Presented by ジョシュア・マダックス

2016年WWDCはApple Pay Webの夜明けを見た。サイトがWebでのストア内にApple Payボタンを埋め込ませるAPIだ。Apple Pay Webをサポートするには、複雑なリクエストフロー、クライアント証明書、および、セッションサーバが要求される。Apple社が信頼できないURLを利用する際の重大な副作用への注意喚起を怠って以来、このことは有害であることを示した。結果として、多くの新たなSSRFの脆弱性が世界に入り込むことになった。さらに悪いことには、それらの脆弱性は同様の方法で悪用・検出が発見可能であるが、いくつかの異なったプログラミング言語で書かれたコードをベースとして広がったため、包括的な方法でパッチを適用することができなかった。 Apple社だけではない。webをひとまとめにする過程でTwilio、Salesforce、その他APIは、すべて同様の幅広い攻撃領域を作り出した。企業がどのように顧客が製品を使うのかを正直かつ親切に見ることに失敗した際には、隠されたセキュリティの負担を押しやってしまう。API組み込む者は、APIを制作した者よりもAPIの背景について詳しくなく、これらのリスクを認識するには更に不利な立場にある。 エンジニアは何十年も防護的なプログラミングについて話をしてきたが、トップ企業は未だにそれを実行するのに困難を抱えている。本講演では、影響を受けたソフトウェアのデモを用いてこれらの過ちを解説し、幅広いクラスのバグ発見のためのパワフルなモデルを紹介する。

レポート

• ソフトウェアのアーキテクチャを間違えた時に、世界中にバグがばらまかれる
• デモを行って、より良いAPIの設計について話す
• Class Breaksの概念
  • Weak Codeは複数の環境に波及する
• もう一つの概念でWeak Code自体を産み出すトップレベルもある
• この概念に既存の用語はない
• inductive weaknessと呼ぶことにする
  • 例えばAPIがSSRFの脆弱性を誘導する
• SSRF Refresher
  • CSRFとは名前はにているが結構違う
  • SSRFは最近ホットトピックになっている
  • 例えばhttp://169.254.169.254/fooへのアクセス
  • GCPやAWSでクレデンシャルが取れる
  • キャピタルワンのように
  • いいニュースもある
  • Google Cloudはデフォルトでこれをやめた
  • このアプローチは有用
• Apple Pay Web
  • Apple Payは3つのフォーム
  • ストアとアプリとWeb
  • 今回はWebだけ
  • WebをサポートするにはAppleのサブドメインに対して通信
  • validationURL
  • Appleの元のコードを使うとサーバからユーザが送ってきたURLにアクセスするとSSRFできる
  • GoogleChromeLabsのGithubから持ってきたコードでのデモ
    • ヘッダを書き換えてSSRFできる
    • CGPのメタデータを取得
    • パーミッションの確認まで
  • webkit.orgのデモ
    • Appleにより管理されている
    • file:///etc/passwdが取れる
  • Appleに連絡した
    • ドキュメントの変更をしただけだった
    • 2月に報告したが意味のある改善がされなかった
  • どうやって緩和するか
    • validationURLをチェックする
    • stripe等を使うと安全
  • mitigations
    • Azure
      • Already okay
    • GCP
      • disableする
    • AWS
      • 有効な手段はない
  • バリデーション
    • おすすめできない
    • regexは難しい
• Webhooks
  • Twilloの例
  • Webhookの認証ではHMACを確認
  • TwilloではHMACを確認していなかった
  • デモ
  • GitlabのwebhooksHMACじゃないトークンが利用されていたが同じような問題があった
  • どこかのWebbookが対象
  • いろいろな方法で安全性を高めることができる
  • 1つのvalidとinvalidMACを確認すればいい
• Appleからはデベロッパーが常にセキュアに保つ必要があると回答した
  • それもそうだがそれだけではないはず
• 最初に手抜きをすると後々高く付くこともある
  • Exampleコードをチェックすることをおすすめする

感想

 

Exampleコードに脆弱性が含まれているのは、普段なかなか想定しないですが怖いですね。

公式のコードだからと信用しきらず、商用化前に、特にレコメンドにあるように導入する段階などなるべく早い段階で検証したいですね。